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ABSTRACT 

Organizational  structure  has  long  been  recognized  as 
having  an  important  impact  on  an  organization's  ability  to 
accomplish  its  objectives.  This  paper  provides  managers  of 
software  development  projects  with  an  analysis  of  the  impor- 
tance of  several  elements  of  organizational  structure,  and 
of  hew  they  can  use  this  knowledge  to  make  decisions  which 
will  have  a  positive  impact  on  the  success  of  their 
projects.  The  structural  elements  discussed  are  specializa- 
tion of  activities,  size  of  the  work  group,  and 
standardization    of    activities. 
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I.    INJRODOCTION 

As  software  development  projects  have  become  more  and 
more  complex,  organizations  have  developed  various  struc- 
tures to  accomplish  them  in  an  effective,  efficient,  and 
timely  manner.  This  aspect  of  the  organizational  adaptation 
process  involves  manipulating  elements  of  organizational 
structure  in  such  a  way  as  to  optimize  the  utilization  of 
the  organization's  scarce  resources.  Stoner  [  Ref .  1]  iden- 
tifies four  major  determinants  of  organizational  structure: 
the  organization's  strategy  for  achieving  its  goals;  the 
skills  and  needs  of  the  people  employed;  the  technology 
employed;  and  the  size  of  the  organization  and  its  subunits. 
Management,  by  making  decisions  concerning  these  determi- 
nants,      seeks      to   develop    the      structure    which    will      be    most 


ee-Pnl 


a?f  75*  •    -\  -i 


sue  cess  rui.  m  accc!n^j.is.nn  ci  trie  'Tna_s  on  trie  crcranxz 
These  managerial  decisions  are  of  extreme  importance  because 
"the  choices  which  top  management  make  are  one  critical 
determinants  of  organizational  structure  and  process." 
[Ref.  2:  p. 548]  Because  of  the  impact  of  these  decisions,  it 
is  very  important  that  managers  of  a  software  development 
project  understand  what  the  elements  of  organizational 
structure  are  and  how  they  can  be  manipulated  to  improve  the 
performance  of   the    development    process. 

Three  elements  of  organizational  structure  noted  by 
Stoner  [Ref.  1]  will  be  the  focus  of  this  paper.  The  first 
element      will   be      the   specialization      of    activities.  This 

concerns  the  br€aking  down  of  the  overall  project  into 
component  activities  and  assigning  personnel  with  special- 
ized training  to  accomplish  those  activities  foe  which  their 
training  makes  them  most  suited,  and  in  which  they  will  be 
most      productive.  The      objective        of      the        chapter      on 


specialization  of  activities  will  be  the  making  the  critical 
dscisicr.s  of  the  optimal  combination  of  specialized  labor  to 
employ,  and  the  optimal  quantity  of  individual  specialized 
labor   to   apply  to  the  software   development    process. 

The  second  element  will  be  the  size  cf  the  work  group. 
An  analysis  of  the  impact  of  work  group  size  on  productivity 
will      be    made.  The      factors      which    influence      work      group 

productivity  will  be  explored,  and  approaches  to  mitigating 
the  negative  factors  while  enhancing  the  positive  factors 
will  be  examined.  The  size  and  composition  of  a  work  grout? 
with  high  productivity  potential  will  be  investigated,  and 
the  manaaerial  and  systems  design  techniques  needed  to 
support    this    work  group    will   also    be    noted. 

The   third   and   final   element      will    be   the    standardization 


or    activities 


The   benefits      of    aotivitv      standardization 


within  a  software  development  project  will  first  be 
discussed  in  general  terms.  The  standardization  cf  one 
phase  cf  the  prccess  will  then  be  analyzed  in  detail  to 
identify  soecific  contributions  and  relevance  to  the  overall 
management    process. 


II.  SPECIALIZATION  OF  ACTIVITIES 

A.   REASONS  FOR  SPECIALIZATION 

One  of  the  most  important  elements  of  organizational 
structure  is  the  specialization  of  activities.  This 
specialization  in  the  organizational  sense  includes  the 
breaking  down  cf  the  project  into  smaller,  specialized 
tasks.  The  benefits  of  ii vision  of  work  have  been  repeat- 
edly demonstrated  throughout  the  history  of  civilization. 
The  order  of  magnitude  improvements  in  productivity 
resulting  from  division  of  work  have  had  profound  impact  on 
the  world's  industrial  development.  Division  of  work  is 
important  because 


no  one  person 

operations  in  lost  complex  tasks,  nor  can  any  one  person 

acquire  all  the  skills  needed  to  perform  the  various 
tasks  that  make  up  a  complex  operation.  Thus,  in  ordar 
to  carry  cut  tasks  requiring  a  number  of  steps,  it  is 
necessarv  no  carcel  cut  the'  various  oarts  of  the  task 
a  mono  a  number 'of  pecDii.  Such  specialized  division  of 
work  allows  oecpie  to  Isarn  skills  and  become  expert  at 
their  individual  iob  functions.  Simplified  tasks' can  be 
learned  in  a  relatively  short  Dsrlod  cf  time  and  be 
completed  quickly.   [Ref.  1:  p.  25^] 


In  a  complex  task  such  as  a  software  development  project 
it  would  be  impractical  to  assign  or.e  person  to  acccmplish 
the  task  by  himself.  In  order  to  achieve  a  high  quality 
product,  this  person  would  not  only  have  to  be  expert  in  all 
areas  of  software  development,  he  would  also  have  to  be  able 
to  provide  his  own  clerical  services,  administative 
services,  computer  services,  etc.  This  one-man  approach  is 
impractical  for  a  multitude  of  reasons,  no4-  the  least  of 
which  is  the  development  time  that  would  be  required.  With 
development  times  for  projects  running   into  the  hundreds  or 
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thousands    of   man-years,      only  the    smallest    of    projects    would 
be    possible.  Therefore,       division      of    work      in    a      complex 

development    project      is   absolutely   essential   to      the    success 
of    the   project. 

B.  SPECIALIZATION  IN  SOFTWARE  PROJECTS 

The  software  development  project  is  often  broken  down 
into  a  sequence  of  tasks,  phases,  or  activities  such  as 
requirements  analysis,  system  design,  system  coding,  system 
test,  etc.  This  division  of  the  overall  -ask  into  many 
subtasks  has  been  widely  discussed  ir.  "rhe  literature. 

As  the  task  itself  is  divided  into  a  variety  of 
subtasks,  so  to  must  the  overall  work  requirement  be  divided 
among  many  individuals.  As  discussed  above,  this  division 
of  labor  is  necessary  to  produce  a  quality  product  within 
time  and  cost  constraints.  The  division  of  labor  allows 
individuals  to  specialize  and  bacoma  expert  at  certain 
skills.  Systems  analysts,  programmers,  technical  analysts, 
and  database  administrators  are  some  cf  the  specializations 
within  software  development  projects.  The  chief  programmer 
team  concept  as  described  by  Brooks  (Ref.  3:  p.  32-35], 
makes  clear  distinctions  between  the  skills,  duties,  and 
responsibilities  Df  its  team  members.  The  specialization 
within  the  chief  programmer  team  includes  a  chief 
programmer,  assistant  programmer,  administrator,  editor, 
secretaries,  clerk,  tooismith,  tester,  and  language  lawyer. 
This  type  of  team,  the  individuals  within  it  and  their 
duties  will  be  discussed  later  in  the  paper. 

C.  MANAGEMENT    DECISIONS 

The  thrust  of  this  chapter  will  be  towards  developing 
generic  conceptual  frameworks  for  the  management  decisions 
concerning  the   combination  and  quantity  of   the  specialized 
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labor  skills  to  employ.     The  following  management  decision 
questions  will  b€  addressed : 

1)  What  is  the  optimal  mix  of  the  different  types  of  labor 
to  employ  in  the  software  development  process? 

2)  What  is  the  optimal  quantity  of  a  particular  type  of 
labor  to  employ? 

1  •   The  Labor.  Mix  Decis  ion 

a.   The  Production  Process 

The  software  development  process  is  a  production 
process  which  transforms  a  particular  sef  of  inputs  (e.g. 
systems  analyst  labor,  programmer  labor,   computer  services, 


etc.)    into  a 
process. 


lesir  ed 


i  at put . 


Figure    2.1      model. 
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Figure  2.1    Software  Development  Hodel, 
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The  relationship  between  the  inputs  into  the 
process  and  the  maximum  output  based  upon  those  inputs 
represents      the    production       function    for      the   process.  In 

other  words,  given  the  technology  applied,  the  output  of  the 
process  is  a  function  of  the  inputs  employed  in  the  process. 
Brooks  [Ref.  3]  and  Fried  [  Ref.  4]  have  demonstrated  that  if 
the  other  inputs  are  held  constant  while  one  type  of  labor 
is  allowed  to  increase,  that  input  will,  at  soma  point,  show 
decreasing  marginal  productivity  and  will  eventually  display 
a  negative  marginal  productivity.  Figure  2.2  illustrates 
the  se    findings    with    respect    to    programmer    labor.         The    slooe 


of   the 


in   Figure    2.2    represents      the    marginal    product 


of      programmer    labor      with    respect 
pro  duced. 


o    total 


lines 


code 


nr.es 

of 
code 


prog  ram msr    labor 


Figure   2.2        Programmer    Labor    Productivity. 
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If  wc  allow  two  of  th9  inputs  to  v=ry,  we  can 
develop  an  isoquant  representing  all  of  the  possible  effi- 
cient combinations  of  these  two  inputs  which  will  produce 
tha  same  quantity  of  output.  For  the  purpose  of  this  argu- 
ment the  two  inputs  used  w ill  be  systems  analyst  labor  and 
programmer  labor.  Figurs  2.3  illustrates  an  isoquant  which 
represents  the  possible  combinations  of  programmer  labor  and 
systems  analyst  labor  capable  of  producing  a  given  quantity 
of  software  (Qs)  . 


ra  no  r 


programmer    labor 


j 


Figure   2.  3        A  Software    Development    Isoquant. 

Points  A  and  3  on  the  isoquant  represent  two 
different  combinations  of  programmer  and  systems  analyst 
labor  capable  of  producing  the  same  amount  of  software;  as 
such,  they  represent  two  different  technological  processes 
(within  the   given  technology)       used   in    the    production    of    the 
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software.  The  slope  of  ths  curve,  therefore,  represents  the 
marginal  rate  of  technological  substitution  (MRTS)  of 
programmer  labor  for  systems  analyst  labor.  It  can  also  be 
shown  that  the  marginal  rate  of  technical  substitution  is 
egual  to  the  ratio  of  ths  marginal  products  of  the  inputs 
[Ref.  5:  p.  158].   In  symbols: 

MRTS   =  -MPp/MPsa  {eqn  2.1) 

w  he  r  e : 

H?p  =  margin  ai  product  of  programmer  labor 

MPsa  =  marginal  product  of  systems  analyst  labor 

MRTS  =  marginal  rats  of  technical  substitution. 

b.   The  Costs 

If  w  <=  assume  that  the  organization  has  a  limited 
amount  of  funds  to  expend  on  ths  inputs  to  ths  production 
process,  and  that  the  total  cost  of  the  fixed  inputs  remains 
constant  and  is  less  than  the  total  amount  available,  then 
there  exists  an  amount  which  is  available  to  partition  among 
the  variable  inputs:  programmer  ani  systems  analyst  labor. 
In    symbols: 

H      =      Pp*Qp   «■    Psa*Qsa  (eqn   2.2) 


whe 

re : 

M 

Fp 

Psa 

QP 

Qsa 

=      the    total  amount   available    for    programmer    and 

systems    analyst    labor 
=      the    price   of    3.    unit    of    programmer   labor 
=      the    price   of    a    unit    of   systems    analyst    labor 
=      the    quantity    of    programmer    labor   used 
=      the    quantity    of    systems    analyst    labor    used. 
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If  we  graph  aquation  2.2  we  car.  represent  the 
various  possible  combinations  of  programmer  and  systems 
analyst  labor  that  can  bs  aguired  for  the  amount  M  by  a 
straight  line  as  in  Figure  2.4  .  This  line  is  called  the 
isocost  curve  for  these  input  combinations.  The  slope  of 
the  isocost  curve  is  negative  and  can  be  shown  to  be  equal 
to  Pp/Psa. 


*Aa 


amount   or 
systems 

analyst 
1  a  bo  r 


amount  of  programmer  labo: 


Figure  2.4    Isocost  Curve. 

If  a  family  of  the  previously  developed  isoguant 
curves  is  superimposed  upon  the  isocost  curve  of  Figure  2.4, 
as  in  Figure  2. 5,  it  is  possible  to  graphically  determine 
the  optimum  mix  of  programmer  and  systems  analyst  labor  to 
employ  in  the  software  development  process. 
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amount    ofn 
systems 

analyst 
labor 


Figure  2.5   The  Optimum  Labor  Mix. 

Q1,  Q2,  and  Q3  represent  isoquants  in  increasing 
order  cf  quantity  of  software  produced.  There  may  be  any 
number  of  isoquar.ts  represented  on  the  graph,  bat  it  can  be 
seen  that  output  will  be  maximized  cor  a  given  cost  (M)  an 
the  point  where  the  isocost  curve  is  tangent  to  the  highest 
isoquant  curve.  In  Figure  2.5  this  is  point  B,  and  02  is 
the  maximum  quantity  of  software  than  can  be  produced  for 
the  given  dollar  amount  available  for  programmer  and  systems 
analyst  labor.  Alternately,  in  could  be  stated  that  M  is 
the  minimum  amount  that  would  have  to  be  spent  on  programmer 
and  systems  analyst  labor,  other  faotors  held  constant,  in 
order  to   produce  a   desired  quantity  Q2.  points  A   and  C 

represer.-"-.  suboptimum  utilization  of  resources  because  the 
same  dollar  amount  is  being  expended  to  produce  a  smaller 
amount  cf   output  (Q1)    than  it   is  possible   of  producing. 
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Additionally,  Figure  2.5  shows  that,  if  other  factors  of 
production  are  held  constant,  it  is  not  possible  to  produce 
more  than  Q2  (for  example  Q3)  with  a  limit  of  a  dollars 
available  for  programmer  and  systems  analyst:  labor. 
Therefore,  from  Figure  2.5  it  is  demonstrated  that  the 
optimum  mix  of  systems  analyst  aid  programmer  labor  is 
represented   by   the   quantities  Qsa   and    Qp  respectively. 

There  is  still  more  information  available  from 
Figure  2.5  .  As  shown  above,  the  slooe  of  the  isocost  curve 
is  equal  tc  -  ne  ratio  of  the  prices  of  the  inputs  (-Pp/Psa) , 
and  the  slope  of  the  isoquant  curve  is  equal  to  the  marginal 
rate  of  technological  substitution  cr  the  ratio  of  the 
marginal    products      of  the   inputs    (-MPp/MPsa)  .  The    optimum 

mix  has  been  shewn  to  be  the  point  of  tangency  between  the 
isocost  curve  an d  the  isoquant  curve.  Therefore,  at  the 
optimum,  the  ratio  of  the  prices  of  the  inputs  will  be  equal 
to  the  ratio  of  their  marginal  products.  The  optimal  combi- 
nation of  programmer  ana  systems  analyst  labor,  therefore, 
is    where: 

Pp/Psa      =      HPp/MPsa  (eqn    2.3) 

or    alternately    where: 

MPsa/Psa      =      HPp/Pp  (eqn    2.4) 

This  second  aquation  reveals  that  the  optimum 
mix  exists  where  the  marginal  productivity  of  a  dollar's 
worth  of  systems  analyst  labor  is  equal  to  a  dollar's  worth 
of    programmer    labor. 
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This  conclusion  makes  intuitive  sense  and  can  be 
generalized  for  any  number  of  inputs  [Ref.  5:  p.  175].  What 
the  relationship  says  is  that  if,  at  any  point,  output  can 
be  increased  by  taking  a  dollar  from  input  X  and  applying 
that  dollar  to  input  Y,  than  it  is  beneficial  to  do  so.  The 
equilibrium  point  will  necessarily  be  where  ^he  ratio  of  the 
marainal    productivity  to   cost   for   all    inputs   is    equal. 

2  •      The,   Labor   £u  ant  i  t  y_    Decision 


mv 


second  problem  is  to  decide  -he  optimal  quantity 


or  an  input  to  utilize 


he  sortware  development  process. 


Programmer  labor  will  be  used  as  a  represents tive  input. 

It  was  shown  above  that  the  marginal  productivity  of 
programmer  labor  in  the  production  of  software,  holding 
other  factors  constant,  is  positive  over  the  relevant  range. 


In  other  words, 


an  incremental  increase  m  programmer 


do: 


prcarammer    labor      required 


will  result,  up  to  a  point,  in  an  incremental  increase  in 
the    amount    of   software   produced.      The    amount    of    the   increase 

mtal 

increase  in  software  produced  is  called  the  marginal  input 
requirement  of  proqrammer  labor  in  the  production  of  soft- 
ware (HIP.p)  .  If  the  market  price  of  programmer  labor  is  ?p, 
than,  in  order  to  achieve  a  marginal  increase  in  software 
production,  a  marginal  cost  (MC)  equal  to  the  price  of 
programmer  labor  multipiiad  by  the  marginal  input  require- 
ment of  programmer  labor  in  the  production  of  software  will 
be    incurred.      The  equation    is: 


MC 


?  p*HIRp 


(eqn    2.5) 


or  alternately,  since  it  can  be  shown  that  the  marginal 
input  reguirement  is  equal  to  the  inverse  of  the  marginal 
product: 
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MC       =       ?p*1/MPp 


(eqn    2.6) 


The  marginal  revenue  (MR)  received  by  selling  the 
incremental  amount  of  software  produced  can  also  be  calcu- 
lated. If  the  market  price  of  the  software  produced  is  Rsr 
then  the  marginal  revenue  is  equal  to  this  market  price 
multiplied  bv  the  increase  in  software  produced  as  a  result 
of  an  incremental  increase  in  oroara^mer  labcr.  This  second 
term  is  the  marginal  product  of  programmer  labcr  in  the 
production    of   software.      The    marginal    revenue   equation    is: 


MB 


Rs*HPo 


(ear.    2.7) 


Because  the  flow  of  funds  for  costs  and  revenues 
occur  a~  different  periods  in  time.  it  is  necessary  to 
discount    them   to    present    values    befor?    comparing    them: 


Present    Value   of    MC 


-ft 

?p*MIFp*e 


(eqn    2.8) 


Present    Value  of   MR      =      Rs*MPp*e 


■rt 


(eqn    2.9) 


The  difference  between  the  present  value  of  the 
marginal  revenue  and  the  present  value  of  the  marginal  cost 
is  the  net  present  value  of  a  marginal  increase  in  the 
amount  of  programmer  labor  used.  If  this  net  present  value 
is  positive,  that  is  if  the  present  value  of  marginal 
revenue  is  greater  than  the  present  value  of  marginal  cost, 
then,  it  is  profitable  to  increase  tie  amount  of  programmer 
labor  used.  If  the  net  present  value  is  negative,  then  it 
is  profitable  to  decrease  the  amount  of  programmer  labor 
used. 
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At  the  optimum,  all  other  factors  remaining 
constant,  programmer  labor  (or  any  other  input)  should  ba 
acquired  to  the  point  whare  the  present  value  of  marginal 
revenue      equals    the      present    value      of      marginal    cost.  In 

symbols    this   is    wher«=: 

-rt  -ft 

Pp*?lIPp*e  =      Rs*MPp*e  (eqn    2.10) 


T, 


"2  r  c  b  1  a  i      in   i  m  pi  3  men  tin  g      this   t  ir  o  e     of   conceptual 


framework  is  the  difficulty  of  ieveioping  an  accurate 
producxicn  function  for  the  software  development  process, 
especially  in  vi=w  of  rh?  paucity  of  good  databases  or.  the 
subject.  A  major  benefit  of  this  type  of  conceptual  frame- 
work is  its  compatibility  with  linear  programming  methods  as 
shown    by    Ein-Dor    and    Jones    [Ref.    6]. 
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HI-     SIZE    DF    THE    WORK    GROUP 

A.  INTRODUCTION 

The  complex  nature  of  software  development  projects  has 
necessitated  the  decomposition  of  the  overall  task  into  a 
multitude  of  lesser  tasks  and  ths  assignment  of  groups  of 
people  to  accomplish  *hose  tasks.  One  would  think  that  the 
larqer  the  group  of  people  assigned  to  a  task,  the  shorter 
would  be  the  completion  time  for  the  task.  Therefore,  in 
order  to  meet  project  deadlines,  attempts  have  been  made  to 
speed  the  completion  of  complex  software  development 
projects  by  simply  adding  more  manpower  to  the  project.  The 
fallacy  of  this  belief  has  been  widely  noted,  most  promi- 
nently in  Brocks'  widely  read  book  The  Mythical  Man  Month  in 
which  Brooks  identified  some  of  the  faotors  which  restrained 
increased  group  size  from  resulting  in  decreased  project 
completion  time;  and  in  which  he  described  how  ''adding 
manpower  ■  to  a  late  software  project  makes  it  later." 
[P.ef.  3:  p.  25]  The  impact  of  this  phenomenon  on  the  soft- 
ware production  function  was  discussed  in  the  previous 
chapter.  This  chapter  will  analyze  how  and  why  the  size  of 
the  work  qrcup  contributes  to  this  phenomenon,  and  how  the 
negative  influence  en  productivity  may  be  mitigated. 

B.  PRODUCTIVITY    IN    GROUPS 

Frcm  studies  as  well  as  from  our  own  work  experience  we 
know  that  members  of  a  group  working  on  a  task  do  net  spend 
all  of  their  time  doing  constructive  work.  Some  percentage 
of  the  time  is  spent  on  coffee  breads,  meetings,  illness, 
training,  vacations,  communicating,  socializing,  etc.  For  a 
10    member    group      "the  non-productive    time    expected      for    each 
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member  is  25  percent  for  vacation  and  the  like;  10  percent 
for  idle  time;  and  a  base  of  10  percent  for  time  spent 
communicating:  a  total  of  45  percent.  We  may  Therefore 
estimate  that  55  percent.  of  each  employees  time  can  be 
considered  productive  in  a  group  of  up  to  10  employees." 
(Ref.  4:  p-  3]  Fried  defines  productivity  in  a  software 
development  project  as  "developing  a  system  with  the 
following  characteristics:  -  Maintainability  (documented, 
modular,  etc.)  -  Effectiveness  (meets  aciual  user  needs) 
Efficiency     (uses    minimal   resources).11      [Ref.    4:    p.    8] 

The  portion  cf  non-productive  time  that  is  most  variable 
with  group  size  is  the  com  municatiop.  time.  If  each  member 
of  the  group  has  to  interact  with  each  other  in  the  accom- 
plishment of  the  task,  the  number  of  interactions  rises 
dramatically  with  the  number  of  peoDle  involved.  If  K  were 
the  number  cf  people  in  the  group,  the  number  of  interac- 
tions   (N)     would    be    given    by    the    for  ma  la: 

N      =      K*  (K-1)  /2  (eqn    3.1) 

This  formula  shows  that  the  number  of  interactions  in 
the  group  increases  in  exponential  fashion  with  an  increase 
in  group  size.  This  comma nica -ions  effort  has  proven  to  be 
a  determining  factor  of  productivity  time  in  a  group.  Fried 
[Ref.  4]  has  developed  the  following  formulae  for  computing 
the    the    percentage   of  productivity    time: 

Px      =      K*(T*    .55   -    .0001*  (K*    K-1    /2)     )  (egn    3.2) 

where : 

Pt  =      productivity    time 

T  =      individual   employee   hours    per    work    period 

K  =  the   number    of    people    in   the    group. 
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The    productivity    percentage    in   the    work    group   is    therefore: 

Pp       =       100*(.55   -    .0001*    K*(K-1)/2    )  (eqn    3.3) 

where  : 

Pp      =      percentage   of    productive    time 

K        =      the   number   of    people    in   the    group. 

Solving  the  above  equations  for  a  10  member  group 
working    a   40    hour   work  week: 

Pt       =       1Q*(40*    .55    -     .0001(10*    10-1    /2)     )     =     213.2 
Pp      =       100*(.55    -    .0001     10*(10-1)/2    )  =     54.55 

whereas    for    an    8  0  member    group    working    the    same    hours: 

Pt       =       80*  (40*    .55    -     .0001*(80*    8  0-1     /2)     )     =    748.8 
Pp      =       100*(.55    -    .0001*    80*(30-1)/2    )  =    23.4 

Table  I  demonstrates  how  the  productivity  percentage 
varies    for    groups   of    various    size. 

Fried  [ Ref-  4],  and  Weinberg  [Sef.  7]  have  experienced 
this  inverse  relationship  between  group  size  and  produc- 
tivity in  complex  projects  with  which  they  have  been 
associated.  Furthermore,         Fried    postulates      that      it      is 

possible  to  reach  a  point  of  negative  marginal  productivity. 
This  is  consistent  with  Brooks'  [Ref.  3]  earlier  findings 
that,  after  a  point,  adding  manpower  can  increase  time  to 
completion    rather  than  decrease    it. 
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C.       SMALL    PROJECT   TEAMS 

The    above    findings   suggest    that,    3 
tivity  time,      project      teams   should    be    created      which   are    of 


iliiiltefl     5IZS. 


A      -earn    with    :wo    memoers    would      seem    to    have 


the      highest    productivity      percentage; 


n  i  ~  -  r^  -n  a 


coordination  and  communication  that  would  be  required 
between  groups,  as  well  as  the  limited  division  of  labor 
possible  within  the  group,  would  eliminate  any  possible 
advantages.  Alternately,  too  large  a  group  results  in  low 
or   negative   marginal    produc  tivity. 

Brooks  [Ref.  3]  encountered  this  dilemma  of  balancing 
the  desireable  aspects  of  email  groups  against  the  absolute 
need  to  produce  the  large  and  complex  OS/360  system  within 
time  and  budget  constraints.  He  described  his  problem  as 
follows: 

For  effiency  and  conceptual  integrity,  one  prefers  a  few 
good  minds  doing  design  and  construction.  Yet  for  large 
systems  one  wants  a  way  to  being  considerable  manpower  to 
bear,  so  that  the  product  can  make  a  timely  appearance.  How 
can    these   two   needs    be  reconciled?"      [Ref*    3:    p.    31] 
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The  answer  that  Brooks  [Ref.  3],  Mills  [  Ref  •  8],  and 
others  have  advocated  is  the  chief  programmer  team  concept. 
This  concept  calls  for  a  10  person  team  headed  by  a  chief 
programmer  who  designs,  codes,  tests,  and  documents  the 
system;  and  who  is  totally  responsible  for  the  product.  All 
the  other  team  members  ars  tasked  with  supporting  the  chief 
programmer  in  his  duties.  The  other  lembers  of  the  team  and 
their    duties    are: 

-  The    "copilot"    vho    serves    as   the   Drimary    assistant    and 
understudy  to    the    chief   programmer; 

-  The   administrator    who    handles    the    logistics    and 
administrative   coordination   for   ths    team; 

-  The    editor    who    reviews    the   chief    programmer's    rough 
documentation    and    performs   the    necessary   editing    and 
reworking   required   to   Droduce  the    final   product; 

-  Two    secretaries,    one   each    for    the    administrator    and   the 
editor,    for    the  necessary    typing,    filing, 
correspondence,   etc.; 

-  The    program   clerk    who    maintains   the    program    product 
library ; 

-  The    "toolsmith"  who   provides    basic    utilities,    creates 
macro   libraries,    and   in   general   facilitates   and    ensures 
the    adeguacy   of  computer    services; 

-  The    tester    who    designs    and    plans    module    and   systems 
testing,    produces    test    oases,    test    data,    etc.; 

-  The   language    lawyer   who    is    expert    in    the    chosen 
programming   language   and    can  adviss    the    chief 
programmer    on    sophisticated  or    intricate   uses    of    the 
language.      [Ref.    3:    pp.    3  2-35] 
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The  hierarchy  of  individuals  performing  specialized 
functions  in  support  of  a  group  leader  not  only  provides  the 
benefits  of  division  of  labor  and  specialization  discussed 
earlier,  it  also  provides  conceptual  integrity  in  design  and 
coding,  as  well  as  simplifying  the  interpersonal  communica- 
tion required.  This  reduot  ion  in  coamunication  requirements 
coupled  with  the  small  size  of  the  team  results  in  a  higher 
productivity  percentage  far  the  team.  Figure  3.1  illus- 
trates the  communication  patterns  within  the  chief 
programmer   team.      [  Ref .    3:    p.    35] 
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Figure   3-1        Coaiunication    Patterns   in    10-Man   Programming   Teams. 


1  •      Social    Dynamics    Considerations 

The  small  size  of  these  teams  and  the  specialization 
of  function  within  them  also  helps  to  mitigate  the  negative 
impact      of   such      social    dynamics      as      the    "Commons      Dilemma" 
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[Ref.  9]  and  "social  loafing"  [ Ref .  10]-  These  dynamics 
suggest  that  individuals  in  a  group  may  use  more  than  their 
share  of  a  common  resource  or  contribute  less  than  their 
share  to  the  common  effort  if  they  feel  that  their  excesses 
or  delinquencies  will  not  be  distinguishable  from  the  common 
consumption  or  effort.  The  small  size  of  the  team  and  the 
specialized  functions  of  the  team  members  in  the  chief 
programmer  team  concept  alleviate  these  problems  by  making 
each  team  member  accountable  for  a  visible,  distinct  secment 
[roup   effort. 

2.      Ensign   Ccnsi derations 

In  order  to  reap  the  benefits  of  small  groups  such 
as  the  chief  programmer  teams  in  large,  complex  projects  i4- 
is  necessary  to  have  many  of  these  teams  working  concur- 
rently in  coordinated  fashion.  To  minimize  the  coordination 
and  management  required,  and  thereby  enhance  the  productive- 
ness of  each  tea  it,  it  is  essential  -hat  the  overall  system 
be  designed  in  a  structured,  modular  manner  with  clear, 
unambiguous   specifications      and    documentation.  Such    stan- 

dardized design  methodologies  will  be  discussed  later  in  the 
paper.  Their      benefit      is   that      they      allow      independent, 

concurrent  production  of  modules  which  can  be  "integrated 
into  the  whole  without  further  coordination."  [Ref.  4:  p. 
10] 

D.       SUMMARY 

The  above  analysis  indicates  that,  in  a  systems  develop- 
ment prelect,  the  size  of  the  work  groups  should  be 
relatively  small.  The  benefits  of  these  small  work  groups 
lie  mainly  in  the  improved  percentage  of  time  spent  produc- 
tively. This  benefit  results  not  only  from  the  fewer  number 
of   communications  within   the   group;    but  also   from   the 
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ability  cf  small,  hierarchically  structured  groups  to  miti- 
gate some  of  the  non-productive  aspects  of  group  dynamics. 
Certain  managerial  and  system  design  techniques  may  be 
required  to  ensure  that  these  benefits  result.  These  tech- 
niques  include: 

-  Proper    schedulinq  and   task:  loading    based   on    an 
understanding  of  "productive    time. 

-  Clear   assignment    of   task  and    product   responsibility , 
accompanied    by   measurement    and   recognition  of 
individual    performance. 

-  Modular   desian    that    supports    cliir    ass  i  an  men  t    of 
product   responsibility!*    [Ref.    4:    p.    10] 
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IV.     STANDARDIZATION    OF    ACTIVITIES 

A.       SEASONS    FOR    STANDARDIZATION 

Standardization  of  activities  is  a  very  important 
element  of  organizational  structure  because  it  is  the  way  in 
which  the  organization  ensures  that  its  efforts  will  produce 
predictable  results  in  the  quantity,  quality,  timeliness, 
and  cost  of  the  software  produced.  in  activity  is  standard- 
ized   when    the   procedure    is    mads    uniform    and    consistent. 

The  advantages  of  standardization  of  activities  have 
long  been  recognized  in  production  processes.  In  an  automo- 
bile assembly  line  the  order  in  which  activities  are 
performed,  the  manner  in  which  they  ire  performed,  the  qual- 
ifications of  workers,  the  rate  of  production,  the  tools, 
par^s,  etc.,  are  ail  highly  standardized.  This  standardiza- 
tion is  one  of  the  reasons  -hat  -his  type  of  production  is 
so  successful.  There  are,  of  course,  significant  differ- 
ences between  automobile  assembly  and  software  development, 
but  the  benefits  of  standardization  of  activities  are  reccg- 
nizeable   in    both    areas. 

The  goals  of  standardization  are  to  produce  predictable 
results  in  quantity,  quality,  timeliness,  and  cost.  The 
quantity  metric  could  be  lines  of  code,  number  of  modules, 
applications  programs  completed,  etc.,  depending  on  manage- 
ment's desired  control  system.  The  quality  metric  is  a 
complex  and  mult  if aceted  one.  What  constitutes  good  soft- 
ware is  a  question  that  continues  to  be  debated. 
Reliability,  predictability,  readability,  maintainability, 
modif iabilty,  flexibility,  robustness,  efficiency,  and 
understandabilit y  are  soma  of  the  concepts  currently  associ- 
ated   with   evaluating    the    quality    of    software. 
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The  timeliness  and  cost:  metrics  are  fairly  simple 
concepts.  The  time  it  -cakes  to  complete  a  project  and  the 
cost  of  the  project  will  vary  with  the  nature  of  the 
project,  assigned  resource s,  etc.;  with  the  general  goal 
being  tc  complete  the  project  within  the  budgeted  cost  and 
time    period.  The    predictability   of      the    above      metrics    is 

itself  a  major  goal  of  standardization.  From  a  management 
viewpoint,  the  predictability  of  the  outcome  of  the  organi- 
zation's efforts  is  absolutely  essential  for  the  planning 
and    control   of   those   efforts. 

B.       SOFTWARE    ENGINEERING 

The  field  cf  software  engineering  has  developed  in 
response  to  the  need  to  improve  and  standardize  the  methods 
and  techniques  enpioyed  in  the  software  development  process. 
The  re  have  been  various  attempts  to  define  the  field  of 
software      engineering.  Wasserman      and      Freeman      [  Ref .    11] 

defined   if    as: 


the  attempt  to  seek  out  and  use  techniques  that  can 
assist  in  the  economical  development  of  software  which 
executes  reiiabiv  and  efficiently  on  real  machines, 
Baking  effective  'use  of  the  human  resources  available. 
Software  Engineering  tries  to  take  an  overall  systems 
viewDcint  in  which  the  optimization  of  ail  resources  - 
developmental  as  well  as  operational  -  is  considered. 
[Ref.    11:    p.    256] 


3.W.    Boehm  [Ref.    12]   shows  a    slightly    different    perspec- 
tive   in   his   definition  of  software   engineering   as: 


the  means  by  which  we  attempt  to  produce  all  of  this 
software  in  a  way  that  is  both  cost-effective  and  reli- 
able enough  tc  deserve  our  trust...  (It  is)  the 
practical  application  of  scientific  knowledge  in  the 
design  and  construction  of  computer  programs  and  the 
associated  documentation  required  to  develop,  operate, 
and    maintain    them.      [Ref.     12:    p.    1227] 
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The  decision  of  which  techniques  and  methodologies  to 
utilize  in  the  software  development  process  is  a  choice  of 
the  technology  tc  employ.  This  choice  is  of  critical  impor- 
tance to  the  development  process  because  the  technology 
employed  serves  to  define  the  software  production  function. 
"The  production  function  summarizes  the  characteristics  of 
the  existing  technology  at  a  given  point  in  time;  it  shows 
the  technological  constraints  that  the  firm  must  reckon 
with."  [Ref,  5:  p.  146]  Therefore,  by  selecting  certain 
techniques  and  methodologies,  and  implementing  them  as  stan- 
dards fcr  the  conduct  of  the  dsvelopaent  process,  the  choice 
of  the  technology  which  will  form  the  boundary  of  the  organ- 
ization's productivity  is  made.  The  importance  of 
structured,  modular  software  design  to  the  implementation 
and  effectiveness  cf  small  project  teams  was  discussed 
earlier  in  this  paper.  To  provide  continuity,  design  meth- 
odologies will  be  used  as  the  example  of  how  activities  in 
the  development  process  are  being  standardized  to  contribute 
to   the   success    of  software    development    projects. 

C.       THE    DESIGN    PHASE 

The  importance  of  standardizing  the  design  phase  cf  a 
software  development  project  has  grown  with  that  of  the 
design  phase  itself.  Developing  standard  design  methods  is 
one  of  the  thrusts  cf  software  engineering  and  many 
approaches  have  been  championed.  The  standard  approaches 
that  have  been  most  widely  accepted  are  those  which  advocate 
a  structured  approach  to  the  design  process.  The  very  term 
"structured"  implies  that  seme  sort  of  standard  method, 
mechanism,         or    approach      is    used.  Stevens,      Myers,         and 

Constantine  [Ref.  13]  have  defined  structured  design  as  "a 
set  of  proposed  general  program  design  considerations  and 
technigues    for    making   coding,         debugging,       and    modification 
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easier,    faster,       and    less    expensive    by    reducing   complexity." 
[Ref.    13:    p.    216] 

1  •      l-CEzDown   De si.gn 

Perhaps  the  best  known  structured  design  technique 
is  Top-down  design  which  results  from  a  stepwise  refinement 
process.  Stepwise      refinement      is        a      methodology      which 

consists   of   the    following   steps: 

1)  Star*    with   a    high-level,    overall    statement   :: 
description   of  the  desired  system    function   made   up 
of:      a)    the  overall  statement   of    the    system   function; 
and    b)     comments/description    of    the    next    level    of 
detail. 

2)  Refine  the  abcve    by  replacing    the    comments/description 

with    a)    lower    level   functions;    and 

b)    comment s/ d esc ript ion    of   the    next    level. 

3)  Repeat   the   refinement    until  ther=    are    no    comments    left 
so    that    the    bottom   level    consists    only    of    functions 
which   can   be    implemented    on   the   hardware/software 

machine. 

This  Top-down  design  can  be  represented  as  a  hier- 
archy of  modules  in  which  the  "uses"  relationship  exists 
between  the  higher  and  lower  level  modules.  The  "uses" 
relationship  can  be  interpreted  as  "requires  the  presence  of 
a  correct   version  of."      [Ref.    14:    p    230] 

Erooks  £Ref.  3]  termed  Top-down  design  "the  most 
important  new  programming  formulation  of  the  (1970-1980) 
decade."  [ Ref.  3:  p.  144  ]  Among  the  benefits  that  Brooks 
attributed  *o  Tcp-dcwn  design  were  four  ways  in  which  if 
assists   the   designer    to   avoid   errors    or    bugs: 


First,    the   clarity    of    structure    and    representation    makes 
the    precise      statement    cf    requirements   and      functions   of 
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the  modules  <=asier.  Second,  the  partitioning  and 
independence  of  modules  avoids  system  bugs.  rhira,  the 
suppression  of  detail  makes  flaws  in  the  structure  more 
apparent.  Fourth,  tha  design  :an  be  tested  at  each  of 
its  refinement  steps,  30  xesting  can  start  earlier  and 
focus  on  the  proper  level  of  detail  at  each  step." 
[Ref.    3:    p.    1431 


The  concepts  of  modularity  and  clear  structure 
present  in  the  Top-down  design  approach  are  represented  in 
the  more  resent  design  approaches  although  the  manner  and 
criteria   of   the    decomposition  have   varied   in   some    cases. 

2«      Designing;  for  Change 

Parnas  [  Hef.  15]  has  proposed  a  design  methodology 
which  focuses  on  designing  software  that  can  be  easily 
changed.  His  approach  uses  a  modular  decomposition  based 
upon  information -hiding  modules  within  a  hierarchical  struc- 
ture. Parnas  £Hef.  15]  proposes  a  design  procedure  which 
would    include: 

1)  Idertifyinci    all    difficult    design    decisions   and    these 
design    decisions    which   are    likely    to    chance. 

2)  Isolating   the   changeable    design    decisions    into 
information-hiding    modules   with   clearly    defined 
interfaces    which    will   be    unaffected    by    potential 
changes. 

3)  Establish   the   "uses"    relationship    between    the    modules. 

4)  Set    up   the    "uses"    hierarchy    by:      a)     listing   the    modules 
at    level    0    (i.e.    those   nodules   which    use    no    other 
module)  ;    and    b)     working    up    the   hierarchy   to    the    top 
level    (i.e.    that    module    which    is    used    by   no   other 
module)  . 


3'4 


Parnas'  approach  to  system  design  has  been  of 
significant  interest  to  those  in  the  software  engineering 
field   because   his   methods: 

1)  Bring    software   design    closer    to    being   a   science. 

2)  Result    in    programs   whioh    are    easier    to    fix   and    modify. 

3)  Result    in    programs   which    are    easily    subsettable    and 
extendable. 

4)  Allow    modules    to    be    programmed   and    tested 
independently   [Ref.    15]. 

Note  that  the  ability  to  independently  program  and 
test  modules  which  is  cited  here  and  in  suseguent  design 
techniques  is  what  was  shown  to  be  naccessary  for  the  effec- 
tive utilization  of  small  Droject  teams  within  a  large, 
complex    project. 

3.      2~§i2H   for    Simple   Connections    and   Functional    linking 

Stevens,  Myers,  and  Const antine  [Ref.  13]  have 
proposed  structured  design  techniques  base!  on  principles 
similar  to  those  of  Parnas.  These  "Techniques  emphasize  a 
structure  of  simply  connected,  functionally  bound  modules. 
They  emphasize  the  use  of  structure  oharts  rather  than  flow- 
charts in  the  design  phase.  Reference  13  provides  the 
somewhat  lengthy  step-by-step  procedure  for  developing  the 
input-process -o utput  general  structure  that  Stevens,  Myers, 
and   Constantine    advocate. 

The   benefits    of   this  design    technique   include: 

1)  Its   ccmpatability    with   the   HIPO    hierarchy   charting 
format   [Ref.     16]. 

2)  Better    maintainability  of   resultant   proqrams. 

3)  Results    in    independently    programmable    and   testable 
modules. 
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4)  Ability   to    identify   ani    optimize    critical    modules. 

5)  Ability   to   develop  reuseable    modules. 

**  •      Des  igni  n,g  Systems    as    Mo  dels 

Jackson  [Ref.  17]  has  proposed  a  different  approach 
to  software  design.  He  argues  that  there  are  some  serious 
disad vantaaes  to  the  functional  approach  to  systems  design. 
Among   the    disadvantages    he    cites   are: 

1)  The   difficulty  of    applying   functional    design   to    complex 
problems. 

2)  The   frequent    requests    for   changes    in    system    function. 


3)    The   lack    of    a   clear   distiction    between    functions   to    be 
performed   by    software    and    those    to    be    performed    by 

hardware. 

Jackson's  approach  is  to  design  the  system  primarily 
as  a  mcdei  of  the  reality  which  it  is  representing  and 
subsequently  superimpose  the  desirei  functions  on  the  model. 
The    steps    in   the    process    are: 

1)  Represent    each  active   entity    in    the    real    world    system   to 
be    modeled   as    a    process    acting   on    a    dedicated    processor. 

2)  Represent    the    communication    between    the    processes 
themselves,    and    between    the    processes    and   the    outside 
world    as    a   data    stream. 


3)     Superimpose    desired   functions   on    the    model. 
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Henard  [ Ref .  18]  of  the  Communications  and  Computer 
Science  Department  of  Exxon  corporation  has  used  Jackson's 
design  method  in  combination  with  top-down  implementation 
and  structured  walkthroughs.  This  combination  was  called 
the    Program   Structure  Technology    (PST) .       Henard    found   that 


the  benefits  derived  from  the  use  of  PSTr  measured 
statistically        for        several        applications,  include 

increased  programmer  productivity  and  reduced  mainte- 
nance costs.  With  PST  as  a  design  method,  the 
programmer  can  produce  double  the  industry  standard 
number  of  lines  of  code  per  year..  The  reduced  mainte- 
nance   cos~?   re  su  1*"      from    —  n  c  o  u  ^  t  -  "  i  n  cr    cs  -^c-    bucjs      in    the 


program    code      and    from      having    the      simpler,      structured 
code    which    is    easier   to   modify."      [  Ref  •    18:    p.    89] 


Menard  [  Sef .  18]  found  that,  whereas  the  PST  method 
required  them  tc  spend  more  time  oi  the  design  phase  of  a 
project,  this  time  was  more  than  made  up  in  the  implementa- 
tion   phase    of   the   project. 

D.       SUHHARY 

The  design  methodologies  discusssed  above  -re  import  ^.n- 
for  providing  conceptually  sound  frameworks  for  the  design 
of  "good"  software;  but,  in  ord=»r  to  realize  the  maximum 
benefit,  the  chosen  methodology  must  be  standardized 
throughout  the  development  project.  It  is  the  standardiza- 
tion of  the  process  which  provides  the  organization  with  the 
benefits  by  reducing  tha  necessity  for  communication  and 
coordination  while  maintaining  design  integrity  and  facili- 
tating  successful  integration. 

The  standards  themselves  form  the  basis  of  the  organiza- 
tion's planning,  control,  and  a  valuation  processes.  Biggs, 
Birks,  and  Atkins  [Ref.  19]  summarized  the  importance  of 
standardization    as    fellows: 


and 

e 

gress    iuringthe   systems      development    pre 
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inhibiting  the  necessary  analytical  and  creative  work 
required  to  produce  successful  new  systems.  The  struc- 
ture allows  management  to  make  and  monitor  incremental 
commitments  and  the  ability  tc  impact  interim  results. 
It  is  an  important  key  to  an  organization's  effective 
management  of  the  systems  development  process. 
[Ref-    19:    p.    47] 


The  importance  of  standardizing  the  activities  in  the 
software  development  process  continues  to  receive  management 
attention.  The  emphasis  on  develODing  standard  methods  and 
approaches  to  requirements  analysis,  specifications,  docu- 
mentation, integration,  and  testing  manifests  the  vital 
importance  of  activity  standardization  in  the  software 
development    process. 


33 


V.     SOMMARX    AND    CONCLOSIONS 

Organizational  structure  has  long  been  recognized  as 
having  an  important  impact  on  an  organization's  ability  to 
accomplish  its  objectives.  Managers,  therefore,  need  tc  be 
aware  of  how  organizational  structure  affects  performance. 
This  paper  has  provided  the  managers  of  software  development 
projects  with  an  analysis  of  the  importance  of  several 
elements  of  organizational  structure ,  and  cf  how  they  can 
use  this  knowledge  to  make  decisions  about  organizational 
structure  which  will  have  a  positive  impact  on  the  success 
of   their    projects. 

The  firs-  structural  element  analyzed  was  the  speciali- 
zation cf  activities.  It  was  founi  that  the  manager  ccul^ 
proceed  with  specific  or  general  knowledge  of  the  software 
production  function  as  provided  by  Brooks  [  Ref .  3],  Fried 
[Ref.  4],  Weinberg  [Ref.  7],  and  Ein-Dcr  and  Jones  [Ref.  6], 
to  develop  conceptual  frameworks  to  assist  in  making  deci- 
sions for  optimizing  the  utilization  of  the  specialized 
inputs  into  the  software  development  process.  Two  of  the 
most  important  decisions  are  the  determination  of  the 
optimal  mix  of  these  inputs,  and  the  determination  of  the 
optimal   guantity    of   a   particular   input    to    aguire. 

The  optimal  mix  cf  the  various  inputs  was  shown  to  exist 
at  that  point  where  the  marginal  productivity  of  a  dollar's 
worth  of  any  input  in  the  production  of  the  software  output 
is  egual  to  the  marginal  productivity  of  a  dollar's  worth  of 
any    other   input. 

The  optimal  guantity  cf  an  input  to  employ,  other 
factors  remaining  constant,  is  that  quantity  at  which  the 
present  value  of  the  marginal  revenue  received  due  tc  a 
marginal      increment    of      the    input      is    equal      to   the      present 
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value  cf  the  marginal  cost  incurred  do  to  that  marginal 
increment. 

This  type  of  conceptual  framework  provides  the  addi- 
tional benefit  of  being  compatible  with  technical  analysis 
and  linear  programming  as  shown  by  Ein-Dor  and  Jones 
[Ref.    6]. 

One  element  of  organ!  zational  structure  that  affects 
labor  productivity  and  thus  the  production  function  is  the 
size  cf  the  work  group.  Brooks  [Ref.  3]  found  that,  after  a 
point,  increases  in  programmer  labor  contributed  less  and 
less  to  software  production  ana  that,  ultimately,  increases 
in  programmer  labor  would  have  a  negative  impact  on  produc- 
tion. Fried  [Ref.  4]  experienced  similar  results  as  did 
Weinberg  [Ref.  7].  Fried  [Ref.  4]  and  Brooks  [Ref.  3]  found 
that  communications  reguirements  were  the  major  factor  in 
reduced      productivity      as      group        size      increased.  Fried 

[Ref.  4]  has  developed  a  formula  from  case  studies  and  prac- 
tical experience  which  can  be  used  to  calculate  the  amount 
of  time  spent  spent  productively  by  a  group  based  upon  the 
size  of  the  croup.  This  formula  and  Weinberg's  [Ref.  7] 
findings  suagest  that  groups  with  more  than  33  people  will 
spend  less  than  50  percent  of  thsir  time  doing  productive 
work. 

Cass  and  Edney  [Ref.  9]  and  Latane,  wiliiams,  and 
Harkins  [Ref.  10]  disco7=red  aspects  of  social  dynamics 
which  also  contribute  to  reduced  individual  productivity  in 
iarae  groups.  These  findings  indicate  that  individuals  tend 
to  use  more  resources  and  contribute  less  effort  if  their 
consumption  and  performance  are  felt  to  be  indist inqishable 
from    that   of   the   group. 

A  possible  solution  to  the  team  size  problem  in  view  of 
these  findings  is  the  chief  programmer  team  concept.  This 
hierarchically  structured,  10  person  team  is  organized  in  a 
manner   which    provides   for    design    integrity,      quality    output, 
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simple  ccmmunica tion  pat-tarns,  visible  job  performance,  and 
high  productivity.  Successful  implementation  of  this  small 
team  concept  in  complex  projects  requires  a  modular  project 
design  as  well  as  managerial  emphasis  on  planning,  control, 
and   evaluation. 

The  achievement  of  good  planning,  control,  and  evalua- 
tion requires  the  standardization  of  software  development 
activities    including:  requirements    analysis,         specifica- 

tions, design,  documentation,  integration,  and  testing.  The 
selection  and  implementation  of  standard  techniques  and 
met hodcicgies  represents  the  choice  of  technology  for  the 
project.  This  technological  choice,  in  turn,  serves  to 
define   the    production   function    for    the    project. 

Stevens,  Myers,  and  Constantine  [ Ref .  13],  Parnas 
[Ref.  15],  and  Jackson  [Ref.  17],  among  others  have  proposed 
software  design  methodologies  which  have  been  used  with 
success  as  the  standard  for  software  projects.  The  modular 
structure  and  clearly  defined  interfaces  resulting  from  the 
structured  design  methodologies  allow  for  the  successful 
division    of    work    among   small,    efficient    programming    teams. 

Biggs,  Birks  and  Atkins  [Ref.  19]  emphasize  the  impor- 
tance cf  activity  standardization  in  all  phases  of  the 
development  process  as  i  key  element  of  organizational 
structure.  Its  importance  is  recognized  not  only  because  it 
makes  effective  planning,  control,  and  evaluation  possible; 
but  alsc  for  the  reduction  in  communication  and  coordination 
it    allows. 

The  field  of  organizational  structure  and  its  impact  on 
organizations'  success  is  vast,  with  myriad  subtle  interre- 
lationships. It  is  an  interdisciplinary  field  with 
applications  from  economics,  operations  research, 
psychology,  sociology,  ana  various  technologies.  This  paper 
has  delved  into  several  of  the  relationships  between 
elements      of      or aanizatioaa 1      structure         and      the      software 
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development  process.  A  common  thread  that  has  appeared  in 
each  element  is  the  software  development  production  func- 
tion. As  the  database  of  development  projects  improves,  so 
too  will  our  ability  to  analyze  and  improve  the  software 
development  process. 
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